This invention relates to a parking meter system which allows rapid communication between parking meter elements at the parking locations and a transportable unit operable by an attendant.
Originally networks were designed for the communication of one computer to a group of other computers, where they all could share dataxe2x80x94this was typically done via a wire such as a coaxial cable. One of the set-backs to all these networks were they were fixed in place and required set up, such as infrastructure. Today, we not only use wires but we are also migrating to a new form of data transferxe2x80x94wireless. The basic fundamental concept of wireless communication is how the frequency spectrum works. The range of frequencies supported by some wireless protocol is referred to as the bandwidth of that protocol; and the transmission rate is proportional to bandwidth.
One available communications protocol is that provided by Ericsson under the trademark xe2x80x9cBluetoothxe2x80x9d which is an open wireless specification of communicating on the 2.4 GHz ISM band. Many wireless applications work on a precise frequency, such as Bluetooth.
Bluetooth utilizes the 2.4 GHz ISM band for wireless communication. This means that we are essentially going to have networks that act like xe2x80x9cplug and playxe2x80x9d hardware for computers. There is not much set up required, just simple authentication on to the system and we can use it, without much configuration or problems.
For our application, we used the Bluetooth wireless standard (our communication protocol is independent of the wireless medium) when this network is installed, it allows simple, embedded micro-controllers to communicate to each other and pass a specific data set to other embedded micro-controllers via a wireless communication link.
Depending on where you go and what system is being implemented in those areas the wireless revolution is growing at an exponential rate, beginning with AMPS (advanced mobile phone service), to wireless LANs based on the IEEE standard or 802.11, personal area networks such as the Bluetooth technology, and wide area networks beginning with AMPS and now including GSM (global system for mobile communications) and CDMA (code division multiple access, which includes second to third generation technologies).
With the advent of wireless networks we are now wanting continuous connection, from our personal area networks, local area networks to our wide area networks. This translates into fixed networks, to wireless networks, to ad-hoc wireless network.
All devices using the Bluetooth open standard will be interoperable. When 802.15 is finalized then we will be guaranteed of the interoperability of all Bluetooth devices.
The 802.15 is the IEEE standard for Personal Area Networks, and more specifically wireless short distance ad-hoc networks. There are 4 main task groups in the 802.15 standard:
With the creation of this new IEEE 802.15 based on the Bluetooth standard, it will become a long lasting standard to be implemented in wireless ad-hoc networking.
The standard for the token ring protocol is Institute of Electrical and Electronics Engineers (IEEE) 802.5.
Performance Improvement Studies in Bluetooth Piconet Formation: Using Knowledge at the Master. S. Balasubramanian, S. P. D. William, A. Swaminathan, A. Siromoney, and M. Rajam. HiPC 2002.
Developing with Qt makes the process of keeping the PDA environment pleasing for a great number of local schemes. For example a 24 hour clock might be more pleasing for some eastern country. Or another country might be more accustomed to another language besides the default for the PDA. For brevity we will refer you to the Qt documentation that in online or that comes with the toolkit download. This seamless feature allows one to code relatively exactly the same and have the Qt framework handle all the details. This will make the introductions to a foreign country much easier. It should be noted that the objects and concepts implemented with QT is not specific to QT, it may be also implemented on Windows, or any type of system that allows for object collaboration.
Currently a city police or a parking ticket officer or attendant is required to walk along the street to inspect each parking meter to see if there is parking violation. Under this Smart Parking Meter System, the officer needs to just carry a handheld device and drive in a car or walk along a street, to patrol streets with parking meters. The device will automatically beep with a red light when it passes by a violated parking stall. Not only with expired parking meters, this can also apply to free limited time parking, say 2-hours free parking. Officers no longer need to mark the tires anymore nor go outside for long hours under harsh weather conditions.
According to the invention there is provided a apparatus for use in controlling parking comprising:
a plurality of parking meter elements each for mounting on a support adjacent a parking location, each parking meter element including:
a payment receptacle operable by a person parking a vehicle for receiving a payment from the person;
a display for displaying an allowable time of parking;
a sensor for detecting the presence of a vehicle in the associated parking location;
a control module responsive to the payment receptacle and the sensor and arranged to control the display;
at least one transportable communication unit for transportation by and manual operation by an attendant including a control module for communicating with the parking meter elements;
the control modules of each of the parking meter elements and the communication unit including communications protocols by which the parking meter element and the communications unit communicate to each other via a wireless medium.
The Smart Parking Meter System is an ad-hoc wireless networking communication protocol. The Smart Parking Meter System communication protocol is implemented within a handheld device and a parking meter, where both devices communicate to each other via a wireless medium. The Smart Parking Meter System protocol can be employed in either a point-to-point wireless system or a multi point wireless system.
This network is job specific, meaning that its network protocol and communication protocol will only be used and accessible to the other systems that use these specific protocols; in this case the Smart Parking Meter clients (or nodes) and servers (or master nodes) will have access to this network only.
There are two hardware components to the Smart Parking Meter System, the handheld device, and the parking meter. The handheld device will require a wireless module either embedded in the system or something which may be connected to the device, such as a PCMCIA (Personal Card Memory Card International Association) card sleeve. The parking meter will require the Smart Parking Meter Application to be installed in each parking meter. The parking meter will require power to be supplied to each meter. The power will be used by the motion sensor for the parking meter to detect an object in its view range (that is, a vehicle or some object in the parking stall), and some embedded device, that will have a wireless module for wireless communication to other parking meters with this system, wireless communication with the handheld device, and the Smart Parking Meter System application.
The embedded system will be required to:
Sense if the meter is in the paid or unpaid state.
Sense if the parking stall is occupied or not.
For limited time parking meters, the device needs to have a motion sensor and will be required to maintain the amount of time the object has been in its view.
A programmable setting is required to define the period of free parking.
It has to have a wireless communication module or an embedded chip to communicate with a remote master device or a remote slave device as well as a handheld device.
1. The handheld device will act as a master for the system meaning that the handheld device will initiate contact with the parking meters.
2. The parking meters will act as masters and slaves within there own network, where a handheld device will always act as a master.
Optionally, it has a programmable timer to set the hours of operation for each parking meter, that is, if there is a meter in a two hour zone.
Three components to the communication protocol for the parking meters:
1. Dynamic Parking Meter Table
Each meter will contain a table of entries, where each entry is the status of a meter on its block. Each meter will have its own block id so meters on another block will not communicate to other meters not on there block.
The size of the parking meter status table is a dynamically created table. As more parking meters are discovered or removed on the block with the same block id, the status table of each meter is passed to each other meter, the status table may increase and decrease in size.
The messaging system deployed within the parking meters is designed to be event driven. In other words, once the state of a given parking meter changes it will notify its neighbors of this change. The neighbors will then propagate this change in state to their neighbors; the message will be dropped once there are no more parking meter devices to be contacted by a given parking meter.
Currently most parking meters have a maximum of 2 hours of parking when paid for. To implement this amount to time we could use a 8 bit representation or one byte. Where the first bit can be one of two states, 0 meaning no object occupying the parking space, or 1, meaning that an object occupying the parking space (or we could use 0 to mean an object is there, and 1 to mean an object is not there). The next 7 bits can represent 127 minutes. If we had a parking meter that had greater than 2 hours than we could use a 2 byte representation when the first bit could indicate whether or not the parking space is occupied or not, then the next 15 bits could represent 32767 minutes. This implementation could be different dependent on what the user would like, how much time the user would like to keep track of, as well as how precise we would like to keep of the time.
2. Connection Priority Thread
This priority thread is used for incoming connection events by other devices (that is from other parking meters and handheld devices). There are two types of incoming priority connection events, the connection event of parking meters is lower than that of the handheld device. Therefore when a handheld device makes a connection to any parking meter, that connection becomes the highest priority event.
3. Internal Task Queue Priority Thread
The internal task queue priority thread was developed to handle multiple race condition situations. An example of this is when a multiple devices are trying to connect to the same device. Since communication with the hardware is not an atomic function. Other devices could establish connections with us when we thought we could create the connection. To handle this type of condition we implemented a lock abstraction. Basically, the task priority threads job is to open a connection to the next device in the current tasks list.
The internal task queue never actually hangs onto a connection lock, the connection lock is only held by the External Connection Priority Thread so the all other internal priority threads know the hardware is busy.
There are two crucial words, in point (2) and point (3), priority and thread. We have implemented two separate applications employing a priority-based system, as well as a thread-based application. The priority-based application puts the task queue priority thread as the highest priority and the connection priority thread as the lowest priority. The thread-based application does not require a priority based system because each individual specialized event will be handled by a separate thread.
There are eight main object abstractions utilized within the handheld device application. These abstractions help co-ordinate application specific tasks as well as wireless communication to the parking meters.
1. City Meters and City Blocks
These object abstractions are designed to logically separate the entire meter network into groups of meters separated into blocks. These two objects need to provide an efficient mechanism for the searching of parking meter nodes and particular blocks.
2. Parking Meters
An abstraction representing a physical meter in the city. This is one object will emit a signal/message to other objects when the state is updated. Any object that wishes to xe2x80x9clistenxe2x80x9d for the signal/message can catch this signal and perform the appropriate action.
3. Meter State
This abstraction is a representation of some parking meters current state. Each parking meters state object is associated with a specific parking meter node.
4. Query Broker
The function of this broker is to managing the queries from other objects within the system.
5. Block Query
This object represents a separate thread of control, or another priority thread. Its responsibilities are to perform a query on a given block inputted by some user. This object handles all the necessary details in discovering and managing all incoming block information. It is also the aggregate for the State Manager object described below.
6. Result Queue
A priority queue based on the block id. Removal and addition of Items is based on the block id. This object needs to be priority and/or threading safe because this object acts as a producer and consumer of information.
7. State Manager
This object is responsible for marinating the state of each meter downloaded and viewed; this includes offering estimations of whether or not a parking meter node should be updated. This involves examining time stamps from the meter state object.
8. Method of Communicationxe2x80x94Worker Priority Thread
An object that wraps the lower level libraries used to communicate to the wireless hardware module in each device.
This object centralizes the devices interaction with the hardware to allow easy hardware error recovery and easy integration of new protocols and schemes for information retrieval.
Smart Parking Meter Systemxe2x80x94Message Passing System/Protocol
The messaging protocol is a brute force algorithm which attempts to counter the problem of creating connections to other devices by using random lengthened delays and multiple connection attempts to eventually to create a connection to other wireless enabled parking meters.
Creating the connection is probably the biggest bottleneck in a large point-to-point or multi point network. The best way to counter this is to use event driven communication so that devices are only attempting to open connections at appropriate times in order to reduce or eliminate paging collisions. Using a system similar to the Token ring protocol, the network is in a constant listening state, and a single master (or possibly two masters at opposite ends of the network) controls the entire network. The master has a list of every parking meter on the current block. It has information about which parking meters can be contacted by other parking meters, although it is not guaranteed to know every communication edge, but it will know enough of them to make a connected system back to itself. If the meters were not configured in a loop then it is able to detect that and take appropriate action.
In a circular configured system all Smart Parking Meter devices are in a listening state. The master of the block (which could be selected by choosing the lowest hardware device address, called the medium access control or MAC layer address) has a routing information list and passes this ordered list to the next address along with the states of all the meters. The meter then looks up the address of the meter after its own entry in the list and pass the list on to it adding its new state to the list. Also to increase the accuracy of the states held in the parking meters, the block master could send out multiple synchronize tokens
Considerations for this system are the configuration stage and meter failure. The configuration stage has to be very robust to allow for high amounts of meter paging and inquiry collisions. As well meter failure could severely cripple the network. If the master disabled, the network would sit idly waiting for instructions from the master not knowing of the master""s untimely demise. These are all special cases though that could be handled in multiple ways. Networks could time-out after a prolonged period of silence and attempt to reconfigure the network and select a new master.
Another consideration for timing accuracy is the use of Hops in the message token. Once a Smart Parking Meter has received the message token, it goes through the list and increment the hop counts of the other meters in the list, and add/update its own state supplying a hop count of 0. We could use an arbitrary number such as 2 seconds/hop, so when the handheld device receives a synchronize event it adjusts the times remaining on the meters by 2 seconds/hop.
Message/Packet Formats
PDA to Meter Message Formats
These messages are used only when the remote master device is communicating with a parking meter. The remote master always initiates them, never by a parking meter.
PDA_SYNC
Description
The PDA_SYNC command is issued only by the remote master device (the iPaq) to a parking meter within range. It currently has no command parameters.
Command Parameters
None
PDA_SYNC_RESULT
Description
The PDA_SYNC_RESULT is sent from the parking meter to the remote master device that initiated the PDA_SYNC. It can contain up to 255 meters and their states.
Command Parameters
PDA_SYNC_RESULT_ACK
Description
The PDA_SYNC_RESULT_ACK is sent from the remote master device after a result has been received to signal to the parking meter what its next action should be.
Command Parameters
PDA_SYNC_COMPLETE
Description
The PDA_SYNC_COMPLETE command is sent from the parking meter to the remote master device to signal that all meter states have been sent. After this the remote master device should close the connection.
Command Parameters
None
Meter to Meter Message Formats
These messages are used by the parking meters to communicate with each other and synchronize the meter states amongst themselves.
METER_SYNC
Description
The METER_SYNC command is sent from the current master parking meter to its slave. It contains the state and address of one parking meter.
Command Parameters
METER_SYNC_ACK
Description
The METER_SYNC_ACK command is sent from the current slave parking meter to its master after a METER_SYNC event. It tells the master if we are ready to receive the next state, or if the current state has to be resent.
Command Parameters
METER_SYNC_DONE
Description
The METER_SYNC_DONE command is sent from the current master meter to the slave to tell the slave that there are no more states to be sent. This allows the two meters to switch roles and now the slave has the opportunity to sent its states to the master. If the meter receiving the METER_SYNC_DONE command has no states to send it closes the connection.
Command Parameters
None
The preferred communications protocol of Bluetooth open specification has 4 parts to it, the HCI (host controller interface), the L2CAP (logical link control and adaptation protocol), SDP (service discovery protocol), and RFCOMM (serial emulation over the L2CAP layer). The present system will support only the HCI, and L2CAP layer protocols to ensure interoperability between different operating system environments, and different Bluetooth devices.
The state of the Bluetooth hardware at the time of this patent was wireless support for only point-to-point Bluetooth hardware chips. The present system is a multipoint ad-hoc network service implemented in software with Bluetooth hardware and embedded systems doing the data processing and I/O control.
As stated previously, there are two separate application platforms for the present system; one is the actual meters themselves, the second is the PDA (personal digital assistant). Both platforms perform specific tasks in the application. The meters are the parking meters that will maintain the state of an individual in violation or not in violation of the meter expiry time. The PDA will be used to upload the state information of the meters on some block given by some map file.
As the synchronize message is passed from meter to meter building a master list so the path back to the PDA is known. This method ensures that all reachable meters are contacted, and that the synchronize message is never repeated. It also allows for quickly passing the paid state list back to the PDA.